1. Field
Embodiments of the invention relate to a software application that automatically detects, troubleshoots, and takes corrective action against problems in the software application.
2. Background
Until a specific version of a software application product, or simply, software product, reaches its End of Service (EOS), it generally will be supported and maintained by the manufacturer or vendor of the software product. During this maintenance period, a number of product defects, configuration issues, environment-specific issues, and invalid use cases, are identified through various customer or end-user feedback or escalations, and through internal (manufacturer) testing. An escalation occurs when a user notices a problem in a software product, and perhaps after trying to solve the problem themselves, raises the issue by contacting the customer service/software support team maintained by the vendor of the software product. If the problem is not resolved by the software support team, they may, in turn, refer the problem to a software maintenance team to fix. The software maintenance team may troubleshoot the problem and apply a software patch, or modification, to the software product, and may even involve the software development team to help fix the problem. In this manner, the problem is “escalated” up the chain of expertise at the customer site and/or the vendor's company until the problem is resolved.
In any case, once identified, these issues are referred to as “known issues” of or related to the specific version of the software product. It is often the case that a large number of customer escalations are raised because of these known issues. Such issues can be confirmed by observing a set of symptoms in the execution of the software product, and can be resolved by providing the corresponding fixes or workarounds, for example, in the form of a software update or patch, known to address the issues. Since there is no mechanism in the software product to automatically identify issues and handle them, the software product's vendor or the vendor's agents may undertake significant customer service and software engineering efforts in the problem troubleshooting process. These efforts may lead to significant costs for the vendor in servicing the software product over the software product's maintenance life cycle. Additionally, for complex problems such as performance and reliability issues, continuous monitoring of the software products in operation and periodically collecting debug information is necessary. Such activities require much effort and time not only of the vendor, but of the customer as well.
There are a number of approaches to troubleshooting and fixing problems in a software product, each with their own drawbacks. Vendors often use “release notes” which, at the time of the release of a specific version of a software product, document the then known set of issues and limitations for the product. The drawback, as indicated, is the release notes only capture the known issues identified at the time of the release of the software product. A user needs to manually check the release notes to confirm whether an issue or problem detected in the software product is a known issue. Additionally, the user will not be aware of the latest set of known issues, those detected and documented after the date the release notes were published, possibly requiring the user to raise service requests to the vendor to initiate troubleshooting and a remedy.
Another approach is for the vendor to document, in a question and answer format, often referred to as Frequently Asked Questions (FAQs), known issues and ways to resolve them. Other information repository tools may also be used to capture and store such information. The drawback with such an approach is that the information sometimes is available only to the vendor's software support team for the product, and may not be exposed to the user. For example, it may be that some or all of the information is not exposed to the user for various reasons such as marketing factors, perceived or actual lack of user's expertise in troubleshooting, and complexity of executing debugging tools and enacting steps to resolve the issue. On balance, this approach requires considerable amount of time and effort of the vendor's software engineering and customer service support staff
There are third party applications that track known problems in software products as well. For example, some product vendors maintain an online repository of known bugs in the Java™ software product where a user can search for a problem description, version and other details. The repository does not provide an automatic troubleshooting approach, however. A user must manually search the repository using appropriate keywords. It is often difficult to confirm whether the user-encountered issue is exactly the same as the bug identified in the repository. Further the repository maintains only the list of bugs in the product; it does not address environmental issues, configuration issues or other invalid use cases the user may be experiencing.
There are some help and support tools built into software products, for example, the help and support tool in Microsoft's Windows operating system and Office software products. This tool is capable of performing as set of debugging steps corresponding to a specific problem by means of a wizard. In a recent version of Microsoft Windows, whenever an error occurs, the software product asks the user's permission to send a report of the error to Microsoft software support. While it is helpful for the software product to send reports on errors, it may be better in some situations to troubleshoot and report logical or functional issues in the software product. However, such issues are common in complex software applications like networking and network management software products. Thus, software product troubleshooting still requires involving a customer service/software support team.
Most software vendors employ the traditional software sustaining process, in which whenever users encounter any issues, they submit service requests to the software vendor. The vendor's customer service/software support team typically can answer simple or moderately complicated software support issues. But some moderately complicated, and most complex, issues require execution of equally complex troubleshooting steps to confirm whether the issue is a known issue or a new issue. In any case, such issues require the help of a software sustaining or maintenance team, and sometimes the software product's development team. Such cases involve complicated and time consuming chain of communication threads between the customer, the customer service team, the software sustaining or maintenance team, and the software development team. What is needed is a way to automate this process.